有没有一种扫码盒子,装流量卡,扫一个url的二维码,然后直接打开网址? |
有成功部署过微服务的案例吗。
能讲下微服务解决的问题,和优缺点。
最好简单明了。
如果不是一两句话说得清,可以推荐下看谁的博客,或者技术文档。
我们是工厂用的流程软件。主要处理作业流程和文档数据处理。微服务和我们业务配套吗。
@chrishine 能解决这些原理是什么,能简单说说吗。
@czz_ls 那和我们现有东西有啥区别,单存就是方便整合吗
微服务必须跟自己公司现有的组织架构,业务规模来结合判断是否适用。
小团队,小数量业务模块根本就不适用,劣势远大于优势。
微服务产生的原因就是,单体应用随着业务需求膨胀,业务模块越来越多,响应需求的研发人员数量也跟着膨胀增加,版本发布的频度同时居高不下。单体应用应付这种情况太吃力。不得已把单体应用拆解解耦成多个独立的业务模块,每个小team负责维护一个模块,模块之间依赖关系由原来的本地调用,改成远程接口调用。
好处是,每个模块的版本可以独立测试、部署、上线,每个team只关心自己的一亩三分地,不需要关心了解庞大的整体项目情况,研发团队职责也非常清晰好管理。坏处是,单体应用原来用单机或主从结构就能应付,现在多主机/进程部署,运维监控管理难度线性上升;team之间,因业务模块接口开发沟通成本也变得巨大,接口升级的管理及其复杂和耗费成本
要我说,用户量庞大的互联网应用比较合适用微服务。像2B的企业应用,绝大多数都不适用微服务。据我观察,行业内真的90%的微服务场景都是瞎用,场景不合适强行硬上,生怕没蹭到这波热度自己技术就落后了
@andyhust 目前是有超过30人维护的。而且比较吃力。新人入门也比较难。业务变化大,人员变化大,很多数据流都不清晰。一个人很难掌握全部代码了。程序问题较多,需要人值班,很折磨人。
比如说,有个地方数据缺失,很难排查原因。重跑一遍程序,数据又能补上。
@letiankaimen 你说的这些问题,微服务一个不拉,全部都有。人员变化大,微服务照样不好维护。至于微服务值班不值班,你看大互联网公司哪个不是24小时on call,这不就是另类值班么。 有那个精力上微服务,还不如找个比较稳定的团队,把当前代码重构一下,不是更美滋滋。
反正微服务这东西,肯定不可能让人轻松的,他设计出来也不是为了干这事的。 哈哈,都是程序员,有一说一,一个系统只要能跑,那他就是成功的好系统,请相信命运,而不要相信用人员变化很大的团队能搭出来另一个能有现在这个性能的系统。
@letiankaimen 这种情况不能把希望寄托在微服务,连单体架构的数据一致性都做不到,微服务架构下那就基本废了。
过早客微信公众号:guozaoke • 过早客新浪微博:@过早客 • 广告投放合作微信:fullygroup50 鄂ICP备2021016276号-2 • 鄂公网安备42018502001446号